home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970104-19970326 / 000353_news@columbia.edu _Tue Mar 4 19:32:34 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  2KB

  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id TAA10718
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Tue, 4 Mar 1997 19:32:34 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id TAA15497
  7.     for kermit.misc@watsun; Tue, 4 Mar 1997 19:32:33 -0500 (EST)
  8. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: FAST+FAST->Window slots 1 of 20
  12. Date: 5 Mar 1997 00:32:31 GMT
  13. Organization: Columbia University
  14. Lines: 31
  15. Message-ID: <5fieuv$md0$1@apakabar.cc.columbia.edu>
  16. References: <5fb64g$5fp@nntp.Stanford.EDU> <5fetck$bde$1@apakabar.cc.columbia.edu> <5fi9d9$ng4@nntp.Stanford.EDU>
  17. NNTP-Posting-Host: watsun.cc.columbia.edu
  18. Xref: news.columbia.edu comp.protocols.kermit.misc:6690
  19.  
  20. In article <5fi9d9$ng4@nntp.Stanford.EDU>,
  21. Stewart Levin <stew@taal.Stanford.EDU> wrote:
  22. : Thanks for all the suggestions I'm working on trying them out.
  23. : Parity Space did not change the slot count, nor did it affect
  24. : the integrity of the transmission.  Sending a big file the
  25. : other direction, PC->Sun did activate 19 of 20 window slots
  26. : over the same connection (and a corresponding satisfying
  27. : increase in throughput.)
  28. Well, first of all remember that the number of window slots
  29. in use will never be more than 1 from the receiver's point
  30. of view unless there have been transmission errors, as explained
  31. on page 258 of "Using C-Kermit" 2nd edition.  The file sender, 
  32. on the other hand, can send a windowful of packets without
  33. receiving any acknowledgements at all, so its window size is
  34. the one that reflects the actual situation.
  35.  
  36. When the local Kermit program is the receiver, you can check the
  37. number of window slots used by the sender after the transfer by
  38. CONNECTing and giving the remote Kermit a STATISTICS command.
  39.  
  40. When file transfers go fast in one direction but slow in the
  41. other, that tends to point the finger to the slow receiver.
  42. Check its Kermit settings carefully (window size, packet
  43. length).  You said you used FAST on both ends, so it's more
  44. likely something else -- a slow disk, a slow or overloaded
  45. computer or terminal server, etc.  If you can be more specific
  46. about the exact type of connection you have and which OS the
  47. PC is using, etc, we can provide better help.
  48.  
  49. - Frank